Thanks, I will take a look at your changes.

What do you think of using the Route 53 REST API directly? This gem already contains the infrastructure for calling the AWS resources directly.

More precisely, what so you see as the benefits of the route53 gem?

The route53 gem provides a complete ruby wrapper around the REST API - this makes creating zones and records idiomatic ruby code. I played around with making REST requests and using that gem, and the gem was substantially easier.

Let me know what you think, but I would definitely recommend going with the gem. If you're opposed to adding dependencies though (which is understandable), it shouldn't be too bad making REST calls.

Let's continue with the gem for now on. It does save us lines of code. Using the AWS REST API directly would result in more consistent code, because we already do the S3 and CloudFront calls with the http_helper.rb file. But, if we later want to convert the Route 53 API calls to that model, it will be fairly easy.

FYI: I've merged your changes into this branch: https://github.com/laurilehmijoki/configure-s3-website/tree/support-route-53. If you plan to make further commits, please base your work on that branch.

I just pushed the commit bcf02cd into the development branch. It contains a Cucumber test for the case where the user wants to setup the main domain and one redirect domain with Route 53. You can run that test by invoking rake cucumber:wip on your command line.

At the moment the output is like this:

       Created bucket morninglightmountain.com in the US Standard Region
       Bucket morninglightmountain.com now functions as a website
       Bucket morninglightmountain.com is now readable to the whole world
       No redirects to configure for morninglightmountain.com bucket
       Created bucket www.morninglightmountain.com in the US Standard Region
       Bucket www.morninglightmountain.com now redirects to morninglightmountain.com
       Do you want to deliver your website via CloudFront, the CDN of Amazon? [y/N]
         The distribution ESJ3PU6AQ080V at d37yyueao74wmk.cloudfront.net now delivers the origin morninglightmountain.com.s3-website-us-east-1.amazonaws.com
           Please allow up to 15 minutes for the distribution to initialise
           For more information on the distribution, see https://console.aws.amazon.com/cloudfront
         Added setting 'cloudfront_distribution_id: ESJ3PU6AQ080V' into features/support/sample_config_files/setup_redirect_domains_with_route_53.yml
       A hosted zone for morninglightmountain.com. does not exist, create one now? [y/N]
       A route already exists for morninglightmountain.com
       Do you want to re-create the existing entry and point it to your S3 bucket/CloudFront? [y/N]
       Unable to remove record for morninglightmountain.com, please do it in the AWS Management console.
       Route53 Entry created for: www.morninglightmountain.com pointing to s3-website-us-east-1.amazonaws.com

Everything else is just great, but the last four lines are confusing. What do you think about them? What causes them? Contrary to what the output says, the route did not exist when I made the configure-s3_website --config-file xxx call.

A question regarding the handling of domain names: why do you take only the last two parts of the domain name? (https://github.com/laurilehmijoki/configure-s3-website/blob/support-route-53/lib/configure-s3-website/route53_client.rb#L103)

Hey man, I'm looking into that bug. Part of it may be that it takes up to 15 min to create a Cloud Front distribution. I'll let ya know what else I find out - I can probably get to it next week.

My approach on the last 2 elements of the domain may not be good, but I did it so that I could find the hosted zones for arbitrary URL. For example, looking at www.testdomain.com, blog.testdomain.com, and testdomain.com - the last two elements of each of those is 'testdomain.com' - this allows me to check the hosted zone for each URL, create it, and then create routes for each URL under that hosted zone. Using that, it will be sure to catch cases where you have another domain name pointing to your blog (i.e.: blog.oldsite.com -> blog.newsite.com).

The only issue I see with that approach is if someone uses a bucket name that doesn't end with '.com' or other top level domain identifier. (As I type this, I'm now thinking of the case 'co.uk')

That behavior of it telling you that the route exists when it does not is definitely unexpected. I'll get to looking at it as soon as I get some time.